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ABOUT THIS CHAPTER 


This chapter describes the Event Manager, the part of the Toolbox that allows 
your application to monitor the user's actions, such as those involving the 
mouse, keyboard, and keypad. The Event Manager is also used by other parts of 
the Toolbox; for instance, the Window Manager uses events to coordinate the 
ordering and display of windows on the screen. 


There are actually two Event Managers: one in the Operating System and one in 
the Toolbox. The Toolbox Event Manager calls the Operating System Event Manager 
and serves as an interface between it and your application; it also adds some 
features that aren't present at the Operating System level, such as the window 
management facilities mentioned above. This chapter describes the Toolbox Event 
Manager, which is the one your application will ordinarily deal with. All 
references to "the Event Manager" should be understood to refer to the Toolbox 
Event Manager. For information on the Operating System's Event Manager, see the 
Operating System Event Manager chapter. 


This chapter also describes four changes that enhance the ability of the 
Macintosh II and Macintosh SE to respond to keyboard events: 


¢ Your application can now work with the Macintosh Plus, Macintosh II, 
and Apple Extended Keyboards, all of which offer several new key 
functions. 

« The event message for keyboard events now distinguishes multiple 
keyboards. 

e A new modifier flag detects the state of the control key on the 
Macintosh Plus and Apple Extended Keyboards. 

e A new Toolbox routine, KeyTrans, helps your application convert key 
codes into ASCII codes. 


Note: Most of the constants and data types presented in this chapter are 
actually defined in the Operating System Event Manager; they're 
explained here because they're essential to understanding the Toolbox 
Event Manager. 


You should already be familiar with resources and with the basic concepts and 
structures behind QuickDraw. 


@ SpInside Macintosh ¢ Version 1.0 * November 1989 « Apple Computer 
THE TOOLBOX EVENT MANAGER ¢ 3 of 38 


ABOUT THE TOOLBOX EVENT MANAGER 


The Toolbox Event Manager is your application's link to its user. Whenever the 
user presses the mouse button, types on the keyboard or keypad, or inserts a 
disk in a disk drive, your application is notified by means of an event. A 
typical Macintosh application program is event-driven: It decides what to do 
from moment to moment by asking the Event Manager for events and responding to 
them one by one in whatever way is appropriate. 


Although the Event Manager's primary purpose is to monitor the user's actions 
and pass them to your application in an orderly way, it also serves as a 
convenient mechanism for sending signals from one part of your application to 
another. For instance, the Window Manager uses events to coordinate the ordering 
and display of windows as the user activates and deactivates them and moves them 
around on the screen. You can also define your own types of events and use them 
in any way you wish. 


Most events waiting to be processed are kept in the event queue, where they're 
stored (posted) by the Operating System Event Manager. The Toolbox Event Manager 
retrieves events from this queue for your application and also reports other 
events that aren't kept in the queue, such as those related to windows. In 
general, events are collected from a variety of sources and reported to your 
application on demand, one at a time. Events aren't necessarily reported in the 
order they occurred; some have a higher priority than others. 


There are several different types of events. You can restrict some Event Manager 
routines to apply only to certain event types, in effect disabling the other 
types. 


Other operations your application can perform with Event Manager routines 
include: 


e directly reading the current state of the keyboard, keypad, and mouse 
button 

* monitoring the location of the mouse 

¢ finding out how much time has elapsed since the system last started up 


The Event Manager also provides a journaling mechanism, which enables events to 
be fed to the Event Manager from a source other than the user. 
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EVENT TYPES 


Events are of various types, depending on their origin and meaning. Some report 
actions by the user; others are generated by the Window Manager, by device 
drivers, or by your application itself for its own purposes. Some events are 
handled by the system before your application ever sees them; others are left 
for your application to handle in its own way. 


The most important event types are those that record actions by the user: 


¢ Mouse-down and mouse-up events occur when the user presses or releases 
the mouse button. 

« Key-down and key-up events occur when the user presses or releases a 
key on the keyboard or keypad. Auto-key events are generated when the 
user holds down a repeating key. Together, these three event types are 
called keyboard events. 

e Disk-inserted events occur when the user inserts a disk into a disk 
drive or takes any other action that requires a volume to be mounted 
(as described in the File Manager chapter). For example, a hard disk that 
contains several volumes may also post a disk-inserted event. 


Note: Mere movements of the mouse are not reported as events. If 
necessary, your application can keep track of them by 
periodically asking the Event Manager for the current location 
of the mouse. 


The following event types are generated by the Window Manager to coordinate the 
display of windows on the screen: 


e Activate events are generated whenever an inactive window becomes 
active or an active window becomes inactive. They generally occur in 
pairs (that is, one window is deactivated and then another is activated). 
e Update events occur when all or part of a window's contents need to be 
drawn or redrawn, usually as a result of the user's opening, closing, 
activating, or moving a window. 


Another event type (device driver event) may be generated by device drivers in 
certain situations; for example, a driver might be set up to report an event 
when its transmission of data is interrupted. The chapters describing the 
individual drivers will tell you about any specific device driver events that 
may occur. 


A network event may be generated by the AppleTalk Manager. It contains a handle 
to a parameter block; for details, see the File Manager chapter. 


In addition, your application can define as many as four event types of its own 
and use them for any desired purpose. 


Note: You place application-defined events in the event queue with the 
Operating System Event Manager procedure PostEvent. See the Operating 
System Event Manager chapter for details. 
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One final type of event is the null event, which is what the Event Manager 
returns if it has no other events to report. 
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PRIORITY OF EVENTS 


The event queue is a FIFO (first-in-first-out) list-—that is, events are 
retrieved from the queue in the order they were originally posted. However, the 
way that various types of events are generated and detected causes some events 
to have higher priority than others. (Remember, not all events are kept in the 
event queue.) Furthermore, when you ask the Event Manager for an event, you can 
specify particular types that are of interest; doing so can cause some events to 
be passed over in favor of others that were actually posted later. The following 
discussion is limited to the event types you've specifically requested in your 
Event Manager call. 


The Event Manager always returns the highest-priority event available of the 
requested types. The priority ranking is as follows: 


1. activate (window becoming inactive before window becoming active) 

2. mouse-down, mouse-up, key-down, key-up, disk-inserted, network, device 
driver, application-defined (all in FIFO order) 

3. auto-key 

4. update (in front-to-back order of windows) 

5 null 


Activate events take priority over all others; they're detected in a special 
way, and are never actually placed in the event queue. The Event Manager checks 
for pending activate events before looking in the event queue, so it will always 
return such an event if one is available. Because of the special way activate 
events are detected, there can never be more than two such events pending at the 
same time; at most there will be one for a window becoming inactive followed by 
another for a window becoming active. 


Category 2 includes most of the event types. Within this category, events are 
retrieved from the queue in the order they were posted. 


If no event is available in categories 1 and 2, the Event Manager reports an 
auto-key event if the appropriate conditions hold for one. (These conditions are 
described in detail in the next section. ) 


Next in priority are update events. Like activate events, these are not placed 
in the event queue, but are detected in another way. If no higher-priority event 
is available, the Event Manager checks for windows whose contents need to be 
drawn. If it finds one, it returns an update event for that window. Windows are 
checked in the order in which they're displayed on the screen, from front to 
back, so if two or more windows need to be updated, an update event will be 
returned for the frontmost such window. 


Finally, if no other event is available, the Event Manager returns a null event. 


Note: The event queue normally has a capacity of 20 events. If the queue 
should become full, the Operating System Event Manager will begin 
discarding old events to make room for new ones as they're posted. 
The events discarded are always the oldest ones in the queue. The 
capacity of the event queue is determined by the system startup 
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information stored on a volume; for more information, see the 
section "Data Organization on Volumes" in the File Manager chapter. 
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KEYBOARD EVENTS 


The character keys on the Macintosh keyboard and numeric keypad generate key- 
down and key-up events when pressed and released; this includes all keys except 
Shift, Caps Lock, Command, and Option, which are called modifier keys. 

(Modifier keys are treated specially, as described below, and generate no 
keyboard events of their own.) In addition, an auto-key event is posted whenever 
all of the following conditions apply: 


e Auto-key events haven't been disabled. (This is discussed further under 
"Event Masks" below. ) 

e No higher-priority event is available. 

« The user is currently holding down a character key. 

e The appropriate time interval (see below) has elapsed since the last 
key-down or auto-key event. 


Two different time intervals are associated with auto-key events. The first 
auto-key event is generated after a certain initial delay has elapsed since the 
Original key-down event (that is, since the key was originally pressed); this is 
called the auto-key threshold. Subsequent auto-key events are then generated 
each time a certain repeat interval has elapsed since the last such event; this 
is called the auto-key rate. The default values are 16 ticks (sixtieths of a 
second) for the auto-key threshold and four ticks for the auto-key rate. The 
user can change these values with the Control Panel desk accessory, by adjusting 
the keyboard touch and the rate of repeating keys. 


Assembly-language note: The current values for the auto-key threshold and 
rate are stored in the global variables KeyThresh 
and KeyRepThresh, respectively. 


When the user presses, holds down, or releases a character key, the character 
generated by that key is identified internally with a character code. Character 
codes are given in the extended version of ASCII (the American Standard Code for 
Information Interchange) used by the Macintosh. A table showing the character 
codes for the standard Macintosh character set appears in Figure 1. All 
character codes are given in hexadecimal in this table. The first digit of a 
character's hexadecimal value is shown at the top of the table, the second down 
the left side. For example, character code $47 stands for "G", which appears in 
the table at the intersection of column 4 and row 7. 


Macintosh, the owner's guide, describes the method of generating the printing 
characters (codes $20 through $D8) shown in Figure 1. Notice that in addition to 
the regular space character ($20) there's a nonbreaking space ($CA), which is 
generated by pressing the space bar with the Option key down. 
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digit First Digit 


{ o 1 2 3 


Ly shands for 4 nonbreaking space, the same width af a digit. 
The shaded characters cannot normally be generated from the 
Macintosh keyboard or keypad. 


Figure 1—Macintosh Character Set 
Figure 1—Macintosh Character Set 


Nonprinting or "control" characters ($00 through $1F, as well as $7F) are 
identified in the table by their traditional ASCII abbreviations; those that are 
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shaded have no special meaning on the Macintosh and cannot normally be generated 
from the Macintosh keyboard or keypad. Those that can be generated are listed 
below along with the method of generating them: 


Cod 


$03 
$08 
$09 
$0D 
$1B 
$1C 
$1D 
$1E 
$1F 


e Abbreviation 


ETX 
BS 
HT 
CR 
ESC 
FS 
GS 
RS 
US 


Key 


Enter key on keyboard or keypad 
Backspace key on keyboard 

Tab key on keyboard 

Return key on keyboard 

Clear key on keypad 

Left arrow key on keypad 

Right arrow key on keypad 

Up arrow key on keypad 

Down arrow key on keypad 


The association between characters and keys on the keyboard or the keypad is 
defined by a keyboard configuration, which is a resource stored in a resource 
file. The particular character that's generated by a character key depends on 


three 


e 


e 


e 


things: 


the character key being pressed 
which, if any, of the modifier keys were held down when the character 


key was pressed 


the keyboard configuration currently in effect 


The modifier keys, instead of generating keyboard events themselves, modify the 
meaning of the character keys by changing the character codes that those keys 
generate. For example, under the standard U.S. keyboard configuration, the "C" 
key generates any of the following, depending on which modifier keys are held 


down: 
Key 
"cu 
"Cc" 
"cu 


“Cc 


(s) pressed 


by itself 


Character generated 


Lowercase C 


with Shift or Caps Lock down Capital C 


with Option down 


Lowercase c with a cedilla( 
used in foreign languages 


with Option and Shift down, or Capital C with a cedilla (C€ 
with Option and Caps Lock down 


¢), 
) 


The state of each of the modifier keys is also reported in a field of the event 
record (see next section), where your application can examine it directly. 


Note: 


As described in the owner's guide, some accented characters are 
generated by pressing Option along with another key for the accent, 
and then typing the character to be accented. In these cases, a 
single key-down event occurs for the accented character; there's no 
event corresponding to the typing of the accent. 


Under the standard keyboard configuration, only the Shift, Caps Lock, and Option 
keys actually modify the character code generated by a character key on the 
keyboard; the Command key has no effect on the character code generated. 
Similarly, character codes for the keypad are affected only by the Shift key. To 
find out whether the Command key was down at the time of an event (or Caps Lock 


@ SpInside Macintosh ¢ Version 1.0 * November 1989 « Apple Computer 


THE TOOLBOX EVENT MANAG 


ER ¢ 11 of 38 


or Option in the case of one generated from the keypad), you have to examine the 
event record field containing the state of the modifier keys. 


The Apple Extended Keyboard 


Apple now offers the Extended Keyboard as an option. Besides all the key 
functions of the present U.S. keyboard and keypad, it contains the following new 
ones: 


¢ Fifteen general Function keys, labeled Fl through F15. Applications 
that use Undo, Cut, Copy, and Paste should assign keys Fl through F4 
to these operations. Keys F5 through F15 are intended to be defined 
by the user, not by the application. 

¢ A Control key. This is included for compatibility with applications 
requiring a Control key, which the Macintosh might access through 
communication with another operating system. It should not be used 
by new Macintosh applications. Pressing it sets bit 12 of the modifiers 
field of the event record for keyboard events. 

e A Help key. This key is available to the user to request help or 
instructions from your application. 

¢ A Forward Delete (Fwd Del) key. Pressing this key performs a forward 
text delete: the character immediately to the right of the insertion 
point is removed and all subsequent characters are shifted left one 
place. When the Fwd Del key is held down, the effect is that the 
insertion point remains stationary while everything ahead of it is 
"vacuumed" away. If it is pressed while there is a current selection, 
it removes the selected text. 

e A Home key. Pressing the Home key is equivalent to moving the vertical 
scroll box to the top and the horizontal scroll box to the far left. 
It has no effect on the current insertion point or on any selected 
material. 

e An End key. Pressing the End key is equivalent to moving the vertical 
scroll box to the bottom and the horizontal scroll box to the far right. 
It has no effect on the current insertion point or on any selected 
material. 

¢ A Page Up key. Pressing the Page Up key is equivalent to clicking in 
the page-up region of the vertical scroll bar of the active window. 
It has no effect on the current insertion point or on any selected 
material. 

e A Page Down key. Pressing the Page Down key is equivalent to clicking 
in the page-down region of the vertical scroll bar of the active window. 
It has no effect on the current insertion point or on any selected 
material. 

¢ Duplicated Shift, Option, and Control Keys. On the Apple Extended 
Keyboard, the Shift, Option, and Control keys occur both to the right 
and to the left of the space bar. Normally they have the same key 
codes. However, it is possible to send the keyboard a command that 
changes the key codes for the keys on the right side. This possibility 
is discussed under "Reassigning Right Key Codes", below. 


Reassigning Right Key Codes 


It is possible to reassign the key codes for the Shift, Option, and Control keys 
on the right side of the Apple Extended keyboard to the following: 
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Right key Raw key code Virtual key code 


Shift $7B 3C 
Option $7C 3D 
Control $7D 3E 


Changing these key codes requires changing the value of the Device Handler ID 
field in the Apple Extended Keyboard's register 3 from 2 to 3. The Device 
Handler ID is described in the Apple Desktop Bus chapter. 


Warning: This capability is included for compatibility with certain existing 
Operating systems that distinguish the right and left keys. Its use 
by new applications violates the Apple user interface guidelines and 
is strongly discouraged. 
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EVENT RECORDS 


Every event is represented internally by an event record containing all 
pertinent information about that event. The event record includes the following 
information: 


« the type of event 

¢ the time the event was posted (in ticks since system startup) 

¢ the location of the mouse at the time the event was posted (in global 
coordinates) 

« the state of the mouse button and modifier keys at the time the event 
was posted 

* any additional information required for a particular type of event, such 
as which key the user pressed or which window is being activated 


Every event has an event record containing this information—even null events. 
Event records are defined as follows: 


TYPE EventRecord = RECORD 


what: INTEGER; {event code} 
message: LONGINT; {event message} 
when: LONGINT; {ticks since startup} 
where: Point; {mouse location} 
modifiers: INTEGER {modifier flags} 

END; 


The when field contains the number of ticks since the system last started up, 
and the where field gives the location of the mouse, in global coordinates, at 
the time the event was posted. The other three fields are described below. 


Event Code 


The what field of an event record contains an event code identifying the type of 
the event. The event codes are available as predefined constants: 


CONST nullEvent = 0; {null} 
mouseDown => 1 {mouse- down} 
mouseUp =" 2s {mouse-up} 
keyDown =. 34 {key -down} 
keyUp = 4; {key -up} 
autoKey =. 5% f{auto-key} 
updateEvt = 6; {update} 
diskEvt = 7; {disk-inserted} 
activateEvt = 8; {activate} 
networkEvt = 10; {network} 
driverEvt = 11; {device driver} 
applEvt = 12; {application-defined} 
app2Evt = 13; {application-defined} 
app3Evt = 14; {application-defined} 
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app4Evt = 15; f{application-defined} 


Event Message 


The message field of an event record contains the event message, which conveys 
additional important information about the event. The nature of this information 
depends on the event type, as Summarized in the following table and described 
below. 


Event type Event message 

Keyboard Character code, key code, and ADB address field 

Activate, update Pointer to window 

Disk-inserted Drive number in low-order word, File Manager 
result code in high-order word 

Mouse-down, Undefined 

mouse-up, null 

Network Handle to parameter block 

Device driver See chapter describing driver 

Application-defined Whatever you wish 


For keyboard events, the low-order byte of the low-order word of the event 
message contains the ASCII character code generated by the key or combination of 
keys that was pressed or released; usually this is all you'll need. However, as 
described in the Apple Desktop Bus chapter, the Macintosh II and SE can be 
connected to multiple keyboards. To identify the origin of keyboard events, the 
keyboard event message contains a new ADB address field. It now has the 
structure shown in Figure 2. 


Warning: The high byte of the event message for keyboard events is reserved 
for future use, and is not presently guaranteed to be zero. 


The event message for non-keyboard events remains the same as described above. 


31 1615 3.7 ) 


a 
_ character code 


key code 


Figure 2-Event Message for Reyboarnd Erents 
Figure 2—Event Message for Keyboard Events 


The key code in the event message for a keyboard event represents the character 
key that was pressed or released; this value is always the same for any given 

character key, regardless of the modifier keys pressed along with it. Key codes 
are useful in special cases—in a music generator, for example—where you want to 
treat the keyboard as a set of keys unrelated to characters. Figure 3 gives the 
key codes for all the keys on the keyboard and keypad. (Key codes are shown for 
modifier keys here because they're meaningful in other contexts, as explained 
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later.) Both the U.S. and international keyboards are shown; in some cases the 
codes are quite different (for example, space and Enter are reversed). 


Three keyboards are now available as standard equipment with Macintosh computers 
sold in the U.S. They are 


e The Macintosh Plus Keyboard, which includes cursor control keys and an 
integral keypad. Its layout and key coding is shown in Figure 4. 

e The Macintosh II Keyboard, also shipped with the Macintosh SE, which 
adds Esc (Escape) and Control keys and is connected to the Apple Desktop 
Bus. Its layout and key coding is shown in Figure 5. 

e The Apple Extended Keyboard, which the user may connect to the Apple 
Desktop Bus of any Macintosh II or Macintosh SE computer. Its layout 
and key coding is shown in Figure 6. 


These figures show the virtual key codes for each key; they are the key codes 
that actually appear in keyboard events. In the case of the Macintosh II and 
Apple Extended Keyboards, however, the hardware produces raw key codes, which 
may be different. Raw key codes are translated to virtual key codes by the 
'KMAP' resource in the System Folder. By modifying the 'KMAP' resource you can 
change the key codes for any keys. Similarly, you can change the ASCII codes 
corresponding to specific key codes by modifying the 'KCHR' resource in the 
System Folder. The 'KMAP' and 'KCHR' resources are described in the Resource 
Manager chapter. 


With both the Macintosh II and the Apple Extended keyboards, the standard 'KMAP' 
resource supplied in the system folder reassigns the following raw key codes to 
different virtual key codes: 


Key Raw key code Virtual key code 
Control 36 3B 
Left cursor 3B 7B 
Right cursor 3C 7C 
Down cursor 3D 7D 
Up cursor 3E 7E 


The standard 'KMAP' resource leaves all other raw key codes and virtual key 
codes the same. 


With the Apple Extended Keyboard, the virtual key codes for three more keys may 
be easily reassigned, as described above under "Reassigning Right Key Codes". 


The following predefined constants are available to help you access the 
character code and key code: 


CONST charCodeMask 
keyCodeMask 


$O00000FF; {character code} 
$0000FFOO; {key code} 
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Figure 4—Macintosh Plus Keyboard 
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Figure 5—Macintosh II Keyboard 
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Figure 6—Apple Extended Keyboard 


Note: You can use the Toolbox Utility function BitAnd with these constants; 
for instance, to access the character code, use 


charCode := BitAnd(my Event.message, charCodeMask)For activate and 
update events, the event message is a pointer to the window affected. (If the 
event is an activate event, additional important information about the event can 
be found in the modifiers field of the event record, as described below. ) 


For disk-inserted events, the low-order word of the event message contains the 
drive number of the disk drive into which the disk was inserted: 1 for the 
Macintosh's built-in drive, and 2 for the external drive, if any. Numbers 
greater than 2 denote additional disk drives connected to the Macintosh. By the 
time your application receives a disk-inserted event, the system will already 
have attempted to mount the volume on the disk by calling the File Manager 
function MountVol; the high-order word of the event message will contain the 
result code returned by MountVol. 


For mouse-down, mouse-up, and null events, the event message is undefined and 
should be ignored. The event message for a network event contains a handle to a 
parameter block, as described in the AppleTalk Manager chapter. For device 
driver events, the contents of the event message depend on the situation under 
which the event was generated; the chapters describing those situations will 
give the details. Finally, you can use the event message however you wish for 
application-defined event types. 


Modifier Flags 


As mentioned above, the modifiers field of an event record contains further 
information about activate events and the state of the modifier keys and mouse 
button at the time the event was posted (see Figure 7). You might look at this 
field to find out, for instance, whether the Command key was down when a mouse- 
down event was posted (which in many applications affects the way objects are 
selected) or when a key-down event was posted (which could mean the user is 
choosing a menu item by typing its keyboard equivalent). 
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Figure 7-Modifier Flazs 
Figure 7—Modifier Flags 


The following predefined constants are useful as masks for reading the flags in 
the modifiers field: 


CONST activeFlag 1; {set if window being activated} 


btnState = 128; {set if mouse button up} 
cmdKey = 256; {set if Command key down} 
shiftKey = 512; {set if Shift key down} 
alphaLock = 1024; {set if Caps Lock key down} 
optionKey = 2048; {set if Option key down} 
ControlKey = 4096; {set if Control key down} 


The activeFlag bit gives further information about activate events; it's set if 
the window pointed to by the event message is being activated, or 0 if the 
window is being deactivated. The remaining bits indicate the state of the mouse 
button and modifier keys. Notice that the btnState bit is set if the mouse 
button is up, whereas the bits for the four modifier keys are set if their 
corresponding keys are down. 
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EVENT MASKS 


Some of the Event Manager routines can be restricted to operate on a specific 
event type or group of types; in other words, the specified event types are 
enabled while all others are disabled. For instance, instead of just requesting 
the next available event, you can specifically ask for the next keyboard event. 


You specify which event types a particular Event Manager call applies to by 
supplying an event mask as a parameter. This is an integer in which there's one 
bit position for each event type, as shown in Figure 8. The bit position 
representing a given type corresponds to the event code for that type—for 
example, update events (event code 6) are specified by bit 6 of the mask. A 1 in 
bit 6 means that this Event Manager call applies to update events; a 0 means 
that it doesn't. 


TOUse-Wyp 
key-own 

kre y-up 
auto-rey 
update 
ditk-inserted 
ackivate 


network 
device driver 
application-defined 
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Figure §-Event Mask 
Figure 8—-Event Mask 


Masks for each individual event type are available as predefined constants: 


CONST mDownMask = 2; {mouse - down} 
mUpMask = 4; {mouse-up} 
keyDownMask = 8; {key -down} 
keyUpMask = 16; {key-up} 
autoKeyMask = 32; f{auto-key} 
updateMask = 64; {update} 
diskMask = 128; {disk-inserted} 
activMask = 256; {activate} 
networkMask = 1024; {network} 
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driverMask = 2048; {device driver} 

app1Mask = 4096; f{application-defined} 
app2Mask = 8192; {application-defined} 
app3Mask = 16384; {application-defined} 
app4Mask = -32768; f{application-defined} 


Note: Null events can't be disabled; a null event will always be reported 
when none of the enabled types of events are available. 


The following predefined mask designates all event types: 
CONST everyEvent = -1; fall event types} 


You can form any mask you need by adding or subtracting these mask constants. 
For example, to specify every keyboard event, use 


keyDownMask + keyUpMask + autoKeyMask 
For every event except an update, use 
everyEvent - updateMask 


Note: It's recommended that you always use the event mask everyEvent unless 
there's a specific reason not to. 


There's also a global system event mask that controls which event types get 
posted into the event queue. Only event types corresponding to bits set in the 
system event mask are posted; all others are ignored. When the system starts up, 
the system event mask is set to post all except key-up event—that is, it's 
initialized to 


everyEvent - keyUpMask 
Note: Key-up events are meaningless for most applications. Your application 


will usually want to ignore them; if not, it can set the system event 
mask with the Operating System Event Manager procedure SetEventMask. 
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USING THE TOOLBOX EVENT MANAGER 


Before using the Event Manager, you should initialize the Window Manager by 
calling its procedure InitWindows; parts of the Event Manager rely on the Window 
Manager's data structures and will not work properly unless those structures 
have been properly initialized. Initializing the Window Manager requires you to 
have initialized QuickDraw and the Font Manager. 


Assembly-language note: If you want to use events but not windows, set the 
global variable WindowList (a long word) to 0 instead 
of calling InitWindows. 


It's also usually a good idea to issue the Operating System Event Manager call 
FlushEvents(everyEvent,0) to empty the event queue of any stray events left over 
from before your application started up (such as keystrokes typed to the 
Finder). See the Operating System Event Manager chapter for a description of 
FlushEvents. 


Most Macintosh application programs are event-driven. Such prorams have a main 
loop that repeatedly calls GetNextEvent to retrieve the next available event, 
and then uses a CASE statement to take whatever action is appropriate for each 
type of event; some typical responses to commonly occurring events are described 
below. Your program is expected to respond only to those events that are 
directly related to its own operations. After calling GetNextEvent, you should 
test its Boolean result to find out whether your application needs to respond to 
the event: TRUE means the event may be of interest to your application; FALSE 
usually means it will not be of interest. 


In some cases, you may simply want to look at a pending event while leaving it 
available for subsequent retrieval by GetNextEvent. You can do this with the 
EventAvail function. 


Responding to Mouse Events 


On receiving a mouse-down event, your application should first call the Window 
Manager function FindWindow to find out where on the screen the mouse button was 
pressed, and then respond in whatever way is appropriate. Depending on the part 
of the screen in which the button was pressed, this may involve calls to Toolbox 
routines such as the Menu Manager function 


MenuSelect, the Desk Manager procedure SystemClick, the Window Manager routines 
SelectWindow, DragWindow, GrowWindow, and TrackGoAway, and the Control Manager 
routines FindControl, TrackControl, and DragControl. See the relevant chapters 
for details. 


If your application attaches some special significance to pressing a modifier 
key along with the mouse button, you can discover the state of that modifier key 
while the mouse button is down by examining the appropriate flag in the 
modifiers field. 
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If you're using the TextEdit part of the Toolbox to handle text editing, mouse 
double-clicks will work automatically as a means of selecting a word; to respond 
to double-clicks in any other context, however, you'll have to detect them 
yourself. You can do so by comparing the time and location of a mouse-up event 
with those of the immediately following mouse-down event. You should assume a 
double-click has occurred if both of the following are true: 


« The times of the mouse-up event and the mouse-down event differ by a 
number of ticks less than or equal to the value returned by the Event 
Manager function GetDblTime. 

« The locations of the two mouse-down events separated by the mouse-up 
event are sufficiently close to each other. Exactly what this means 
depends on the particular application. For instance, in a word-processing 
application, you might consider the two locations essentially the same 
if they fall on the same character, whereas in a graphics application 
you might consider them essentially the same if the sum of the horizontal 
and vertical changes in position is no more than five pixels. 


Mouse-up events may be significant in other ways; for example, they might signal 
the end of dragging to select more than one object. Most simple applications, 
however, will ignore mouse-up events. 


Responding to Keyboard Events 


For a key-down event, you should first check the modifiers field to see whether 
the character was typed with the Command key held down; if so, the user may have 
been choosing a menu item by typing its keyboard equivalent. To find out, pass 
the character that was typed to the Menu Manager function MenuKey. (See the Menu 
Manager chapter for details.) 


If the key-down event was not a menu command, you should then respond to the 
event in whatever way is appropriate for your application. For example, if one 
of your windows is active, you might want to insert the typed character into the 
active document; if none of your windows is active, you might want to ignore the 
event. 


Usually your application can handle auto-key events the same as key-down events. 
You may, however, want to ignore auto-key events that invoke commands that 
shouldn't be continually repeated. 


Note: Remember that most applications will want to ignore key-up events; 
with the standard system event mask you won't get any. 


If you wish to periodically inspect the state of the keyboard or keypad-say, 
while the mouse button is being held down—use the procedure GetKeys; this 
procedure is also the only way to tell whether a modifier key is being pressed 
alone. 


Responding to Activate and Update Events 


When your application receives an activate event for one of its own windows, the 
Window Manager will already have done all of the normal "housekeeping" 
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associated with the event, such as highlighting or unhighlighting the window. 
You can then take any further action that your application may require, such as 
showing or hiding a scroll bar or highlighting or unhighlighting a selection. 


On receiving an update event for one of its own windows, your application should 
usually call the Window Manager procedure BeginUpdate, draw the window's 
contents, and then call EndUpdate. See the Window Manager chapter for important 
additional information on activate and update events. 


Responding to Disk-Inserted Events 


Most applications will use the Standard File Package, which responds to disk- 
inserted events for you during standard file saving and opening; you'll usually 
want to ignore any other disk-inserted events, such as the user's inserting a 
disk when not expected. If, however, you do want to respond to other disk- 
inserted events, or if you plan not to use the Standard File Package, then 
you'll have to handle such events yourself. 


When you receive a disk-inserted event, the system will already have attempted 
to mount the volume on the disk by calling the File Manager function MountVol. 
You should examine the result code returned by the File Manager in the high- 
order word of the event message. If the result code indicates that the attempt 
to mount the volume was unsuccessful, you might want to take some special 
action, such as calling the Disk Initialization Package function DIBadMount. See 
the File Manager and Disk Initialization Package chapters for further details. 


Other Operations 


In addition to receiving the user's mouse and keyboard actions in the form of 
events, you can directly read the keyboard (and keypad), mouse location, and 
state of the mouse button by calling GetKeys, GetMouse, and Button, 
respectively. A new routine in the 256K ROM lets your application convert key 
codes to ASCII values as determined by a 'KCHR' resource. The 'KCHR' resource 
type is discussed in the Resource Manager chapter. To follow the mouse when the 
user moves it with the button down, use StillDown or WaitMouseUp. 


The function TickCount returns the number of ticks since the last system 
startup; you might, for example, compare this value to the when field of an 
event record to discover the delay since that event was posted. 


Finally, the function GetCaretTime returns the number of ticks between blinks of 
the "caret" (usually a vertical bar) marking the insertion point in editable 
text. You should call GetCaretTime if you aren't using TextEdit and therefore 
need to cause the caret to blink yourself. You would check this value each time 
through your program's main event loop, to ensure a constant frequency of 
blinking. 
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TOOLBOX EVENT MANAGER ROUTINES 


Accessing Events 


FUNCTION GetNextEvent (eventMask: INTEGER; 
VAR theEvent: EventRecord) : BOOLEAN; 


GetNextEvent returns the next available event of a specified type or types and, 
if the event is in the event queue, removes it from the queue. The event is 
returned in the parameter theEvent. The eventMask parameter specifies which 
event types are of interest. GetNextEvent returns the next available event of 
any type designated by the mask, subject to the priority rules discussed above 
under "Priority of Events". If no event of any of the designated types is 
available, GetNextEvent returns a null event. 


Note: Events in the queue that aren't designated in the mask are kept in 
the queue; if you want to remove them, you can do so by calling the 
Operating System Event Manager procedure FlushEvents. 


Before reporting an event to your application, GetNextEvent first calls the Desk 
Manager function SystemEvent to see whether the system wants to intercept and 
respond to the event. If so, or if the event being reported is a null event, 
GetNextEvent returns a function result of FALSE; a function result of TRUE means 
that your application should handle the event itself. The Desk Manager 
intercepts the following events: 


* activate and update events directed to a desk accessory 
* mouse-up and keyboard events, if the currently active window belongs to 
a desk accessory 


Note: In each case, the event is intercepted by the Desk Manager only if 
the desk accessory can handle that type of event; however, as a rule 
all desk accessories should be set up to handle activate, update, and 
keyboard events and should not handle mouse-up events. 


The Desk Manager also intercepts disk-inserted events: It attempts to mount the 
volume on the disk by calling the File Manager function MountVol. GetNextEvent 
will always return TRUE in this case, though, so that your application can take 
any further appropriate action after examining the result code returned by 
MountVol in the event message. (See the Desk Manager and File Manager chapters. ) 
GetNextEvent returns TRUE for all other non-null events 

(including all mouse-down events, regardless of which window is active), leaving 
them for your application to handle. 


GetNextEvent also makes the following processing happen, invisible to your 
program: 


¢ If the "alarm" is set and the current time is the alarm time, the alarm 
goes off (a beep followed by blinking the apple symbol in the menu bar). 
The user can set the alarm with the Alarm Clock desk accessory. 

e If the user holds down the Command and Shift keys while pressing a 
numeric key that has a special effect, that effect occurs. The standard 
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such keys are 1 and 2 for ejecting the disk in the internal or external 
drive, and 3 and 4 for writing a snapshot of the screen to a MacPaint 
document or to the printer. 


Note: Advanced programmers can implement their own code to be executed in 
response to Command-Shift-number combinations (except for Command- 
Shift-1 and 2, which can't be changed). The code corresponding to a 
particular number must be a routine having no parameters, stored in 
a resource whose type is 'FKEY' and whose ID is the number. The 
system resource file contains code for the numbers 3 and 4. 


Assembly-language note: You can disable GetNextEvent's processing of Command- 
Shift-number combinations by setting the global 
variable ScrDmpEnb (a byte) to 0. 


FUNCTION EventAvail (eventMask: INTEGER; 
VAR theEvent: EventRecord) : BOOLEAN; 


EventAvail works exactly the same as GetNextEvent except that if the event is in 
the event queue, it's left there. 


Note: An event returned by EventAvail will not be accessible later if in 
the meantime the queue becomes full and the event is discarded from 
it; since the events discarded are always the oldest ones in the queue, 
however, this will happen only in an unusually busy environment. 


Reading the Mouse 
PROCEDURE GetMouse (VAR mouseLoc: Point); 


GetMouse returns the current mouse location in the mouseLoc parameter. The 
location is given in the local coordinate system of the current grafPort (which 
might be, for example, the currently active window). Notice that this differs 
from the mouse location stored in the where field of an event record; that 
location is always in global coordinates. 


FUNCTION Button : BOOLEAN; 


The Button function returns TRUE if the mouse button is currently down, and 
FALSE if it isn't. 


FUNCTION StillDown : BOOLEAN; 


Usually called after a mouse-down event, StillDown tests whether the mouse 
button is still down. It returns TRUE if the button is currently down and there 
are no more mouse events pending in the event queue. This is a true test of 
whether the button is still down from the original press—unlike Button (above), 
which returns TRUE whenever the button is currently down, even if it has been 
released and pressed again since the original mouse-down event. 


FUNCTION WaitMouseUp : BOOLEAN; 


WaitMouseUp works exactly the same as StillDown (above), except that if the 
button is not still down from the original press, WaitMouseUp removes the 
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preceding mouse-up event before returning FALSE. If, for instance, your 
application attaches some special significance both to mouse double-clicks and 
to mouse-up events, this function would allow your application to recognize a 
double-click without being confused by the intervening mouse-up. 


Reading the Keyboard and Keypad 
PROCEDURE GetKeys (VAR theKeys: KeyMap) ; 


GetKeys reads the current state of the keyboard (and keypad, if any) and returns 
it in the form of a keyMap: 


TYPE KeyMap = PACKED ARRAY[0..127] OF BOOLEAN; 


Each key on the keyboard or keypad corresponds to an element in the keyMap. The 
index into the keyMap for a particular key is the same as the key code for that 
key. (The key codes are shown in Figure 3 above.) The keyMap element is TRUE if 
the corresponding key is down and FALSE if it isn't. The maximum number of keys 
that can be down simultaneously is two character keys plus any combination of 
the four modifier keys. 


FUNCTION KeyTrans (transData: Ptr; keycode: Integer; 
VAR state: LONGINT) : LONGINT; [256K ROM] 


KeyTrans lets your application convert key codes to ASCII values as determined 
by a 'KCHR' resource. The 'KCHR' resource type is discussed in the Resource 
Manager chapter. 


TransData points to a 'KCHR' resource, which maps virtual key codes to ASCII 
values. The keycode parameter is a 16-bit value with the structure shown in 
Figure 9. 


1h fo 7 6 a 


Virtua key code 


Figure 9-Reyoode Parameter Structore 
Figure 9—Keycode Parameter Structure 


The state parameter is a value maintained by the Toolbox. Your application 
should save it between calls to KeyTrans. If your application changes transData 
to point to a different 'KCHR' resource, it should reset the state value to 0. 


KeyTrans returns a 32-bit value with the structure shown in Figure 10. In this 
structure, ASCII 1 is the ASCII value of the first character generated by the 
key code parameter; reservedl is an extension for future "16-bit ASCII" coding. 
ASCII 2 and reserved2 have the same meanings for a possible second character 
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generated by key code—for example, if key code designates an alphabetic 
character with a separate accent character. 


al i429 1h 15 oF 0 


Fesarved1 £500 1 Reserved? A592 


Figure 10-ReyTrans Reto Stuctire 
Figure 10—KeyTrans Return Structure 
Assembly-language note: The macro you invoke to call KeyTrans from assembly 


language is named KeyTrans. Its parameters are 
passed on the stack. 


Miscellaneous Routines 
FUNCTION TickCount : LONGINT; 


TickCount returns the current number of ticks (sixtieths of a second) since the 
system last started up. 


Warning: Don't rely on the tick count being exact; it will usually be 
accurate to within one tick, but may be off by more than that. The 
tick count is incremented during the vertical retrace interrupt, 
but it's possible for this interrupt to be disabled. Furthermore, 
don't rely on the tick count being incremented to a certain value, 
such as testing whether it has become equal to its old value plus 1; 
check instead for "greater than or equal to" (since an interrupt 
task may keep control for more than one tick). 


Assembly-language note: The value returned by this function is also contained 
in the global variable Ticks. 


FUNCTION GetDblTime : LONGINT; [Not in ROM] 


GetDblTime returns the suggested maximum difference (in ticks) that should exist 
between the times of a mouse-up event and a mouse-down event for those two mouse 
clicks to be considered a double-click. The user can adjust this value by means 
of the Control Panel desk accessory. 


Assembly-language note: This value is available to assembly-language 
programmers in the global variable DoubleTime. 


FUNCTION GetCaretTime : LONGINT; [Not in ROM] 


GetCaretTime returns the time (in ticks) between blinks of the "caret" (usually 
a vertical bar) marking the insertion point in editable text. If you aren't 
using TextEdit, you'll need to cause the caret to blink yourself; on every pass 
through your program's main event loop, you should check this value against the 
elapsed time since the last blink of the caret. The user can adjust this value 
by means of the Control Panel desk accessory. 
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Assembly-language note: This value is available to assembly-language 
programmers in the global variable CaretTime. 
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THE JOURNALING MECHANISM 


So far, this chapter has described the Event Manager as responding to events 
generated by users—keypresses, mouse clicks, disk insertions, and so on. By 
using the Event Manager's journaling mechanism, though, you can "decouple" the 
Event Manager from the user and feed it events from some other source. Such a 
source might be a file into which have been recorded all the events that 
occurred during some portion of a user's session with the Macintosh. This 
section briefly describes the journaling mechanism and some examples of its use, 
and then gives the technical information you'll need if you want to use this 
mechanism yourself. 


Note: The journaling mechanism can be accessed only through assembly 
language; Pascal programmers may want to skip this discussion. 


In the usual sense, "journaling" means the recording of a sequence of user- 
generated events into a file; specifically, this file is a recording of all 
calls to the Event Manager routines GetNextEvent, EventAvail, GetMouse, Button, 
GetKeys, and TickCount. When a journal is being recorded, every call to any of 
these routines is sent to a journaling device driver, which records the call 
(and the results of the call) in a file. When the journal is played back, these 
recorded Event Manager calls are taken from the journal file and sent directly 
to the Event Manager. The result is that the recorded sequence of user-generated 
events is reproduced when the journal is played back. The Macintosh Guided Tour 
is an example of such a journal. 


Using the journaling mechanism need not involve a file. Before Macintosh was 
introduced, Macintosh Software Engineering created a special desk accessory of 
its own for testing Macintosh software. This desk accessory, which was based on 
the journaling mechanism, didn't use a file—it generated events randomly, 
putting Macintosh "through its paces" for long periods of time without requiring 
a user's attention. 


So, the Event Manager's journaling mechanism has a much broader utility than a 
mechanism simply for "journaling" as it's normally defined. With the journaling 
mechanism, you can decouple the Event Manager from the user and feed it events 
from a journaling device driver of your own design. Figure 11 illustrates what 
happens when the journaling mechanism is off, in recording mode, and in playback 
mode. 
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Figure 11-The Joumaling Mechanism 
Figure 11—The Journaling Mechanism 


Writing Your Own Journaling Device Driver 


If you want to implement journaling in a new way, you'll need to write your own 
journaling device driver. Details about how to do this are given below; however, 
you must already have read about writing your own device driver in the Device 
Manager chapter. Furthermore, if you want to implement your journaling device 
driver as a desk accessory, you'll have to be familiar with details given in the 
Desk Manager chapter. 


Whenever a call is made to any of the Event Manager routines GetNextEvent, 
EventAvail, GetMouse, Button, GetKeys, and TickCount, the information returned 
by the routine is passed to the journaling device driver by means of a Control 
call. The routine makes the Control call to the journaling device driver with 
the reference number stored in the global variable JournalRef; the journaling 
device driver should put its reference number in this variable when it's opened. 


You control whether the journaling mechanism is playing or recording by setting 
the global variable JournalFlag to a negative or positive value. Before the 
Event Manager routine makes the Control call, it copies one of the following 
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global constants into the csCode parameter of the Control call, depending on the 
value of JournalFlag: 


JournalFlag Value of csCode Meaning 
Negative jPlayCtl .EQU 16 Journal in playback mode 
Positive jRecordCtl .EQU 17 Journal in recording mode 


If you set the value of JournalFlag to 0, the Control call won't be made at all. 


Before the Event Manager routine makes the Control call, it copies into csParam 
a pointer to the actual data being polled by the routine (for example, a pointer 
to a keyMap for GetKeys, or a pointer to an event record for GetNextEvent). It 
also copies, into csParam+4, a journal code designating which routine is making 
the call: 


Control call csParam contains Journal code 

made during: pointer to: at csParam+4: 

TickCount Long word jcTickCount .EQU 0 
GetMouse Point jcGetMouse -EQU 1 
Button Boolean jcButton .EQU 2 
GetKeys KeyMap jcGetKeys .EQU 3 
GetNextEvent Event record jcEvent .EQU 4 
EventAvail Event record jcEvent .EQU 4 
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SUMMARY OF THE TOOLBOX EVENT MANAGER 


Constants 
CONST 


{ Event codes } 


nullEvent = Q; {null} 

mouseDown =< 31s {mouse- down} 

mouseUp =: -2% {mouse-up} 

keyDown = 3; {key -down} 

keyUp = 4; {key -up} 

autoKey =. 53 f{auto-key} 

updateEvt = 6; {update} 

diskEvt =a TS {disk-inserted} 
activateEvt = 8; {activate} 

networkEvt = 10; {network} 

driverEvt = 11; {device driver} 
applEvt = 12; {application-defined} 
app2Evt = 13; {application-defined} 
app3Evt = 14; {application-defined} 
app4Evt = 15; {application-defined} 


{ Masks for keyboard event message } 


charCodeMask 
keyCodeMask 


$OQ00000FF; {character code} 
$0000FFOO; {key code} 


{ Masks for forming event mask } 


mDownMask = 2; {mouse - down} 

mUpMask = 4; {mouse-up} 
keyDownMask = 8; {key -down} 

keyUpMask = 16; {key-up} 

autoKeyMask = 32; f{auto-key} 

updateMask = 64; {update} 

diskMask = 128; {disk-inserted} 
activMask = 256; {activate} 
networkMask = 1024; {network} 

driverMask = 2048; {device driver} 
app1Mask = 4096; f{application-defined} 
app2Mask = 8192; f{application-defined} 
app3Mask = 16384; {application-defined} 
app4Mask = -32768; {application-defined} 


{ Modifier flags in event record } 


activeFlag = 1; {set if window being activated} 
btnState = 128; {set if mouse button up} 
cmdKey = 256; {set if Command key down} 
shiftKey = 512; {set if Shift key down} 
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alphaLock 1024; {set if Caps Lock key down} 


optionKey = 2048; {set if Option key down} 
ControlKey = 4096; {set if Control key down} 
Data Types 
TYPE 
EventRecord = RECORD 
what: INTEGER; {event code} 
message: LONGINT; {event message} 
when: LONGINT; {ticks since startup} 
where: Point; {mouse location} 
modifiers: INTEGER {modifier flags} 
END; 


KeyMap = PACKED ARRAY[0..127] OF BOOLEAN; 


Routines 
Accessing Events 
FUNCTION GetNextEvent (eventMask: INTEGER; 
VAR theEvent: EventRecord) : BOOLEAN; 
FUNCTION EventAvail (eventMask: INTEGER; 
VAR theEvent: EventRecord) : BOOLEAN; 


Reading the Mouse 


PROCEDURE GetMouse (VAR mouseLoc: Point); 
FUNCTION Button : BOOLEAN; 
FUNCTION StillDown : BOOLEAN; 


FUNCTION WaitMouseUp : BOOLEAN; 
Reading the Keyboard and Keypad 
PROCEDURE GetKeys (VAR theKeys: KeyMap); 
FUNCTION KeyTrans (transData: Ptr; keycode: Integer; 
VAR state: LONGINT) : LONGINT; [256K ROM] 
Miscellaneous Routines 
FUNCTION TickCount : LONGINT; 


FUNCTION GetDblTime : LONGINT; [Not in ROM] 
FUNCTION GetCaretTime : LONGINT; [Not in ROM] 


Event Message in Event Record 
Event type Event message 


Keyboard Character code, key code, and ADB address field 


@ SpInside Macintosh ¢ Version 1.0 * November 1989 * Apple Computer 
THE TOOLBOX EVENT MANAGER ¢ 35 of 38 


Activate, update Pointer to window 


Disk-inserted Drive number in low-order word, File Manager 
result code in high-order word 

Mouse-down, Undefined 

mouse-up, null 

Network Handle to parameter block 

Device driver See chapter describing driver 

Application-defined Whatever you wish 


Assembly-Language Information 
Constants 


sEvent codes 


nullEvt . EQU 0 snull 

mButDwnEvt . EQU 1 ;mouse-down 
mButUpEvt .EQU 2 ;mouse-up 

keyDwnEvt . EQU 3 ; key-down 

keyUpEvt . EQU 4 ;key-up 

autoKeyEvt .EQU 5 ;auto-key 

updatEvt .EQU 6 ;update 
diskInsertEvt .EQU 7 ;disk-inserted 
activateEvt . EQU 8 ;activate 

networkEvt . EQU 10 ;network 

ioDrvrEvt . EQU 11 ;device driver 
applEvt . EQU 12 ;application-defined 
app2Evt . EQU 13 ;application-defined 
app3Evt .EQU 14 ;applLication-defined 
app4Evt . EQU 15 ;application-defined 


; Modifier flags in event record 


activeFlag .EQU 0 ;set if window being activated 
btnState . EQU 2 ;set if mouse button up 

cmdKey . EQU 3 ;set if Command key down 
shiftKey .EQU 4 ;set if Shift key down 
alphaLock . EQU 5 ;set if Caps Lock key down 
optionKey .EQU 6 ;set if Option key down 


; Journaling mechanism Control call 


jPlayCtl .EQU 16 ;journal in playback mode 

jRecordCtl . EQU 17 ;journal in recording mode 

jcTickCount .EQU 0 ;journal code for TickCount 

jcGetMouse .EQU 1 ;journal code for GetMouse 

jcButton . EQU 2 ;journal code for Button 

jcGetKeys .EQU 3 ;journal code for GetKeys 

jcEvent . EQU 4 ;journal code for GetNextEvent and EventAvail 


Event Record Data Structure 


evtNum Event code (word) 
evtMessage Event message (long) 
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evtTicks Ticks since startup (long) 


evtMouse Mouse location (point; long) 

evtMeta State of modifier keys (byte) 

evtMBut State of mouse button (byte) 

evtBlkSize Size in bytes of event record 

Variables 

KeyThresh Auto-key threshold (word) 

KeyRepThresh Auto-key rate (word) 

WindowList 0 if using events but not windows (long) 

ScrDmpEnb 0 if GetNextEvent shouldn't process Command-Shift-number 
combinations (byte) 

Ticks Current number of ticks since system startup (long) 

DoubLleTime Double-click interval in ticks (long) 

CaretTime Caret-blink interval in ticks (long) 

JournalRef Reference number of journaling device driver (word) 


JournalFlag Journaling mode (word) 
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Further Reference: 


OS Event Manager 
Technical Note #3, Command-Shift-Number Keys 

Technical Note #5, Using Modeless Dialogs from Desk Accessories 
Technical Note #85, GetNextEvent; Blinking Apple Menu 


END OF DOCUMENT 
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